Clean Architecture 達人に学ぶソフトウェアの構造と設計
ソフトウェア設計の本 読んでる
3章 設計の原則
SRP 単一責任の原則
一つのクラスやモジュールに色々責務を持たさない
異なるステークホルダーのやりたきことなら、クラスを分ける。
データとロジックを分離する。
一つしか関数がなかったとしても、いずれ増えるし、Private関数はあるはず
OCP オープン・クローズドの原則
ソフトウェアの構成要素は拡張に対しては開いていて、修正に対して閉じていなければならない
コンポーネントAがコンポーネントBの変更から保護されるべきならば、コンポーネントBからコンポーネントAへ依存すべきである
ロジックは、ビューに依存しないとかはその一つ
DIP 依存関係逆転の原則を使えば、反転できる。
また、あるコンポーネントがあるコンポーネントに依存しすぎないことも重要
中身を知りすぎないように、インタフェースで情報を隠蔽する。
依存先の変更に強くなる。
とてもよい説明だったmactkg.icon
LSP リスコフの置換原則
置き換えても安心！
アーキテクチャレベルでも思考できる
ISP インタフェース分離の原則
必要のないものに依存していると、必要のないもののおかげで変更が必要になったりする、話
DIP 依存関係逆転の法則
変化しやすいものに依存したくない
継承は依存関係である。という話、なるほど感あるmactkg.icon
何かに対して変更をかけることは、依存するということだmactkg.icon
オーバーライドなり、継承なり
FactoryPattern
ここはよくわからなかったなmactkg.icon
4章 コンポーネントの原則
コンポーネント
デプロイの単位
Java: jar
Ruby: gem
コンポーネントとは、リンカだった。リンカの発明
コンポーネントの凝集性
REP 再利用・リリース等価の原則
再利用の単位と、リリースの単位は等価になる
バージョン管理されていて、意味のある、凝集性のある単位でコンポーネントが分割されていることが大事
CCP 閉鎖性共通の原則
やっぱり、package by feature, not layerですね。
CRP 全利用の原則
コンポーネントのユーザーに対して、実際に使わないものへの依存を強要してはいけない。
ISPと一緒。不要なものに依存するな。
テンション図が良い
https://gyazo.com/6ae93c69c1d58d4330369b21cda1b278
プロジェクト初期は右側。
後半は左側。どのように使われるのか？を意識する
あとがき
プログラマにアーキテクチャを任せるときの問題は、プログラマがアーキテクトのように考えなければいけないということだ。ビックアーキテクチャ時代に学んだすべてのことに価値がなかったわけではない。ソフトウェアの構造は（たとえそれが短期的であっても）ソフトウェアを適応・進化させる我々の能力に大きな影響を与える可能性がある。
すべての設計決定には、将来変更する余地を残しておく必要がある。たとえばビリヤードでは、すべてのショットがボールを落とすためにあるわけではない。次のショットにつなげるためのショットも必要である。それと同じで、将来のコードを阻害しないコードを書くことも必要だ。それは簡単なことではない。習得するには何年もかかるだろう。